[Min & Max] Rewritten to ternary operation#235
[Min & Max] Rewritten to ternary operation#235SiarheiBarysenka wants to merge 1 commit intoswiftlang:masterfrom
Conversation
|
I generated two SILs (attached) for min-if and min-ternary. You are right regarding additional var as min-if has stack management routine, while min-ternary SIL does not. Not sure is it optimized anyway further down the line or not, but no matter what the resulting output for min-ternary should be less or equal to min-if, while readability definitely better. I am dying out of curiosity to see what was the reason to write min & max as it is now. |
|
I don't have the IEEE 754-2008 spec handy, but IIRC min() and max() for floating-point types should return the non-NaN value if there is a (quiet) NaN involved. It looks like the floating-point types end up in these functions. I don't know what the plans are around correcting this behavior. Perhaps @stephentyrone or @gribozavr can weigh in on that? |
|
I don't see why ternary-based code would be faster. The optimizer should generate the same code. If you are interested in making other improvements in this area, please read the discussion in #137. |
Use a whitelisting model for configuring which rules to use.
[pull] swiftwasm from master
[Concurrency] Add support for 'async' on closures.
Refactor common leading arguments out and add --distcc.
4 participants
It seems ternary operation here prevents creating additional
var, which might be a bit faster. It also makes code more readable.